Many companies and other organizations deploy large-scale distributed applications across numerous execution platforms to provide various types of services to their internal and external customers. For example, some organizations may set up complex, multi-tier applications that use dozens or even hundreds of virtualized compute servers and/or storage servers, potentially spread over many different geographically distributed data centers, for access by customers over public and/or private network connections. Various components of such applications may interact with one another to respond to customer requests—e.g., a web server instance of a multi-tier web application may interact with an application server instance or a database server to produce the results requested from a client browser. The behavior of the different application components (e.g., the perceived responsiveness to end-user requests) may in many cases be sensitive to the value of various configuration parameters. Another application deployment model that has gained traction in recent years involves the download and deployment of relatively self-contained application instances or modules to large numbers of mobile devices such as smart phones, tablets and the like. In some approaches, each instance of a mobile application may have its own set of configuration settings, such that changing settings may require re-deployment or re-installation of the application.
Depending on the complexity of the functionality supported by a given distributed application, and the different types of resources used by the application, a substantial amount of configuration information may be required to manage and control the various components of the application. Historically, different application vendors have taken their own approaches towards configuration management. A few application providers, such as vendors of some database management systems, provide fairly sophisticated proprietary tools to configure and monitor their applications. Such vendor tools may, however, themselves require a steep learning curve before administrators new to the tools can become effective. Other vendors rely on approaches such as text configuration files in various formats, which may become hard to parse and understand for non-trivial application sizes.
For some kinds of applications, it may in general be desirable to ensure consistent configuration of each of multiple application instances or components, while at the same time being able to support non-standard configurations for some subset of the instances or components. For example, one network-intensive application may be deployed to a hundred servers in a data center, of which ninety servers use one type of network interface card (NIC), five servers happen to use a different NIC, and five servers happen to use a third NIC. The general goal for this application may be to have a common NIC configuration for all the servers where the application is running, assuming the most common NIC is in use, while also being able to configure the less common NICs when needed. If a new version of the application is released, which requires different settings for the different NIC types, administrators may in some environments have to manually track down exactly which changes are needed at which servers, and then apply the changes, which may be an error-prone process. The problem of efficiently implementing desired changes to configurations may be even more of an issue for mobile applications which can potentially be deployed at hundreds of thousands, or even millions, of smart phones or tablets. For information technology (IT) departments whose staff has to potentially manage hundreds of different applications, the widely different approaches taken to configuration management by the different applications can lead to substantial costs—e.g., due to inadvertent less-than-optimal configuration settings, or manual replication effort required to try to maintain consistent configurations.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.